The present invention relates to a method and apparatus for communicating data via a packetized data stream, and more particularly to the transmission of high rate isochronous data in an MPEG-2 data stream. The invention also provides for the communication of a data clock increment value to a decoder to provide a simplified and cost effective approach to the direct digital synthesis (DDS) of a clock frequency necessary to recover data from the packetized data stream at the decoder.
Various standards have emerged for the transport of digital data, such as digital television data. Examples of such standards include the Motion Picture Experts Group standard referred to as MPEG-2 and the DigiCipher.RTM. II standard proprietary to General Instrument Corporation of Chicago, Ill., U.S.A., the assignee of the present invention. The DigiCipher II standard is similar and inclusive of various aspects of the MPEG-2 standard, which is widely known and recognized as a video and audio compression specification sanctioned by the International Standards Organization (ISO) in Document ISO 13818.
In addition to the video and audio compression features, the MPEG-2 specification also contains a systems "layer" that provides a transmission medium independent coding technique to build bitstreams containing one or more MPEG programs. The MPEG coding technique uses a formal grammar ("syntax") and a set of semantic rules for the construction of bitstreams to be transmitted. The syntax and semantic rules include provisions for multiplexing, clock recovery, synchronization and error resiliency. For purposes of this disclosure, any data stream that is coded similarly to that of an MPEG-2 transport stream is referred to as an "MPEG-2 type transport stream." One example, but by no means the only such MPEG-2 type transport stream, is a data stream provided in accordance with the DigiCipher II standard. Other such standards are expected to be promulgated in the future.
The MPEG-2 transport stream is specifically designed for transmission in conditions that can generate data errors. MPEG transport packets each have a fixed length of 188 bytes. Many programs, each with different components, may be combined in a transport stream. Examples of services that can be provided using the MPEG format are television services broadcast over terrestrial, cable television and satellite networks as well as interactive telephony-based services. The syntax and semantics of the MPEG-2 transport stream are defined in the International Organisation for Standardisation, ISO/IEC 13818-1, International Standard, 13 Nov. 1994 entitled "Generic Coding of Moving Pictures and Associated Audio: Systems," recommendation H.222.0, and ISO/IEC 13818-2, International Standard, 1995 entitled "Generic Coding of Moving Pictures and Associated Audio: Video," recommendation H 262, both incorporated herein by reference.
Multiplexing according to the MPEG-2 standard is accomplished by packaging raw elementary streams such as coded video and audio into packetized elementary stream (PES) packets which are then inserted into transport packets. As noted above, each MPEG transport packet is fixed at 188 bytes in length. The first byte is a synchronization byte having a unique eight-bit pattern, e.g., 01000111. The sync byte is used to locate the beginning of each transport packet.
Following the sync byte is a three-byte prefix which includes a one-bit transport packet error indicator, a one-bit payload unit start indicator, a one-bit transport priority indicator, a 13-bit packet identifier (PID), a two-bit transport scrambling control, a two-bit adaptation field control, and a four-bit continuity counter. Use of the sync byte and three-byte prefix leaves up to 184 bytes of payload which carry the data to be communicated. An optional adaptation field may follow the prefix for carrying both MPEG related and private information of relevance to a given transport stream or the elementary stream carried within a given transport packet. Provisions for clock recovery, such as a program clock reference (PCR) and splicing control are typical of the information carried in the adaptation field. By placing such information in an adaptation field, it becomes encapsulated with its associated data to facilitate remultiplexing and network routing operations. When an adaptation field is used, the payload is correspondingly shorter.
The PCR is a count which reflects the value of the system time clock (STC) for the associated program at the time the PCR bytes were inserted into the transport stream. The decoder uses the PCR to synchronize a decoder time clock with the encoder system clock. The lower nine bits of the 42-bit PCR provide a modulo-300 counter that is incremented at a 27 MHz clock rate (the "system clock rate"). At each modulo-300 rollover, the count in the upper 33 bits is incremented, such that the upper bits represent counts that occur at a 90 kHz rate. This enables presentation time-stamps (PTS) and decoding time-stamps (DTS) to be compared using the 90 kHz value. Since each program or service carried by the data stream may have its own PCR, the programs and services can be multiplexed asynchronously.
Synchronization of audio, video and data within a program is accomplished using a time stamp approach. Presentation time-stamps and decoding time-stamps are inserted into the transport stream for the separate video and audio packets. The PTS and DTS information is used by the decoder to determine when to decode and display a picture and when to play an audio segment. As indicated above, the PTS and DTS values are tied to the same clock established by the PCRs, but are limited by the MPEG-2 standard to a time resolution of 11.1 microseconds. This resolution is limited by the PTS resolution of 90 kHz ticks, provided by the upper 33 bits of the PCR. This limitation precludes the transport of generalized "high rate" data which is robust to timing errors, e.g., data rates not integer related to 90 kbps, using the same approach provided for video and audio information in a standard MPEG-2 type transport stream.
MPEG-2 data, such as compressed video and audio data, must be formatted into a packetized elementary stream (PES) formed from a succession of PES packets. Each PES packet includes a PES header followed by a payload. The PES packets are then divided into the payloads of successive fixed length transport packets.
PES packets are of variable and relatively long length. Various optional fields, such as the presentation time-stamps and decoding time-stamps may follow the PES header. When the transport packets are formed from the PES, the PES headers are aligned with the transport packet headers. A single PES packet may span many transport packets and the subsections of the PES packet must appear in consecutive transport packets of the same PID value. It should be appreciated, however, that these transport packets may be freely interleaved with other transport packets having different PIDs and carrying data from different elementary streams.
Video services are carried by placing coded MPEG video streams into PES packets which are then divided into transport packets for insertion into a transport stream. Each video PES packet contains all or part of a coded video picture, referred to as a video "access unit." PTS and DTS data are placed into the PES packet header that encapsulates the associated access unit. The PTS is used to actuate the decoder to present (e.g., "display") the associated access unit. The DTS indicates when the decoder should decode the access unit.
Audio services are provided in accordance with the MPEG standard using the same specification of the PES packet layer. PTS data is attached to those packets that include audio frame boundaries. Such boundaries are defined by audio sync words. An audio frame is defined as the data between two consecutive audio sync words.
In order to reconstruct a television signal from the video and audio information carried in an MPEG-2 type (e.g., MPEG-2 or DigiCipher II) transport stream, a decoder is required to process the video packets for output to a video decompression processor (VDP) and the audio packets for output to an audio decompression processor (ADP). It is also possible to transmit other types of data in such a transport stream. For example, private data to provide services such as teletext, stock quotes and other information can be carried as separate transport packets derived from a separate packetized elementary stream. Asynchronous data pipes can be supported as well; such a pipe would represent an RS-232 style output from the decoder with the equivalent input to an encoder. Such information service transport packets would be multiplexed with the MPEG video and audio packets in a final multiplex transmitted, e.g., via satellite or cable.
It would be advantageous to also carry "isochronous" data using an MPEG-2 type format. Isochronous data is high rate data delivered at the edges of a regular clock and is distinguished from bursty "synchronous" data which may arrive with an irregular clock. Thus, isochronous data carries a jitter specification and the clock can be restored with a simple phase lock loop (PLL). In general, an isochronous data component is one in which data bits are delivered at essentially regular rates, with an accompanying clock. Any deviation from the regular (isochronous) rate would be covered by the allowed jitter specification. Such data may be used for any number of a large range of "data pipe" applications. One example is the transport of the contents of a T1 digital (i.e., telephone data line) data stream. Such data streams operate at 1,554 Mbps. Other applications include, but are not limited to, business network data, general high speed data communications, and virtually any other data service requiring constant delay data transmission rates that exceed those generally available using asynchronous communication techniques or are not appropriate for variable delay. These applications are characterized by a general intolerance of "bit slips." That is, errors are tolerated, but resynchronization involving net shifts of the bitstream cause large outages to the ultimate data synchronization.
In the MPEG-2 standard, the presentation time-stamps are only able to point to presentation units (i.e. 8-bit bytes of data "presented" to the decoder) at a resolution of 11.1 microseconds. This limitation results from the 90 kHz rate established by the upper bits of the PCR count used to produce the presentation time-stamps. With high speed isochronous data, it may be necessary to resolve presentation units with a higher resolution, especially for purposes of error recovery. Specifically, it is necessary to be capable of presenting presentation units unambiguously in time to support continuously variable rates. Therefore, it would be advantageous to increase the time resolution of the presentation time-stamps over that provided by a standard MPEG-2 implementation. For example, it would be advantageous to provide a scheme for increasing the PTS time resolution to allow the robust transport of isochronous data or the like at rates up to 9.0 Mbps or more.
It would be further advantageous to provide a scheme for simplifying a data receiver to provide the appropriate clock rates based on a system clock frequency, in order to recover data from a data stream. In particular, it would be advantageous to provide a scheme in which the receiver would be able to provide a clock at any desired information data rate from, e.g., 19.2 kbps to 9 Mbps for use in outputting isochronous information data, via DDS.
The present invention provides a method and apparatus for transmitting and receiving data in an MPEG-2 type transport stream having the aforementioned and other advantages.